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DETAILED ACTION 

Claim Rejections - 35 USC § 103 

1 . The following is a quotation of 35 U.S.C. 1 03(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set 
forth in section 102 of this title, if the differences between the subject matter sought to be patented and 
the prior art are such that the subject matter as a whole would have been obvious at the time the 
invention was made to a person having ordinary skill in the art to which said subject matter pertains. 
Patentability shall not be negatived by the manner in which the invention was made. 

2. Claims 1,3-6,8-11,14,15,1 7-20, 22-25, 27, 28 and 62 are rejected under 35 
U.S.C. 103(a) as being unpatentable over Ogawa et al. (Design and implementation of 
DV based video over RTP. Proc. Packet Video2000, 2000), hereinafter Ogawa and in 
view of Ben-Dor et al., hereinafter Saito, (US PAT PUB 2002/0141418, hereinafter Ben- 
Dor). 

Regarding claim 1, Ogawa teaches a Packet processing apparatus, and packet 
processing method comprising: a. a packetizing one or more data streams into 
isochronous data packets; b. encapsulating one or more isochronous data packets 
according to a real- time transport protocol to form a real-time transport protocol data 
packet; and c. sending the real-time transport protocol data packets from a transmitting 
device to a receiving device over a non-isochronous compliant network (sections 4-4.1, 
we implemented IP based DV video transmission system called DV Transport 
System(DVTS) using DV/RTP[5][6]. The overview of the DVTS is shown in Fig. 2. The 
system consists of a Pentium based PC with FreeBSD as an operating system, 
IEEE1394 device driver and interface^], and DV/RTP stream sender and receiver 
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application. Both DV/RTP sender and receiver PC have an IEEE 1394 interface on the 
PCI bus. The camcorder connected DV/RTP sender side (Shown in the left side of Fig. 
2) creates IEEE1394 encapsulated DV packet stream. The sender application receives 
the DV stream via PCI IEEE1394 interface card, encapsulates the DV packet of 
IEEE1394 into RTP, and transmits it to the IP network. The receiver application obtains 
the IEEE1394 DV packets by reconstructing DV data received using RTP. IEEE1394 
header is attached to the reconstructed DV/IEEE1394 packet and transferred to the DV 
recorder deck via PCI IEEE1394 interface card (Shown in the right side of Fig. 2). The 
DV recorder deck displays the DV data on the connected display. The DV system we 
implemented has the advantage that the system can be configured only with highly 
available standard PCI based PC compatibles, consumer DV camcorder and DV VCR 
equipment having IEEE1394 interface. In order to use consumer DV devices equipped 
with IEEE1394 interface, we designed and implemented an IEEE1394 device driver on 
FreeBSD 3.3[7]. IEEE1394 high speed serial bus system is designed for a packet based 
shared media computer bus system. The network bandwidth is logically specified from 
100Mbps to 3.2Gbps. The goal of IEEE1394 is to integrate and observe various 
interface and cable specification into only single bus (cable) system, i.e. storage device 
interface instead of SCSI and IDE, peripheral of parallel and serial, network of ethernet, 
processor interconnect of VME and also RCA cable of audio and visual equipment. 
Heterogeneous speed devices can be connected within a single IEEE1394 physical 
network, which enables devices are made at the appropriate cost. Three types of 
transmission mode is provided by IEEE1394; 1)isochronous stream mode for QoS 
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which provides especially strict packet jitter and guaranteed bandwidth without reliable 
communication, 2) asynchronous stream for best effort without reliability, and 
3)asynchronous request for the reliable communication. Data timing in IEEE1394 is 
shown in Fig 3. Every packet transmission action is brought with 8 kHz time slice whose 
value corresponds to the fairness unit in the IEEE1394 system. The 8kHz time slice unit 
is also divided into 6144 time slot for bandwidth management. Isochronous stream 
transmission would be done by taking the number of time slot the sender requires first, 
sending a packet whose size is smaller than the time slot at every 8kHz fairness unit. 
Therefore, the packet jitter of the isochronous stream mode is suppressed in the order 
of 8kHz (125 micro second), and the condition might be enough for any jitter sensitive 
high quality packet video system. It is not easy for the legacy packet based shared 
network system to satisfy such conditions. However, every IEEE1394 LSI chip already 
supports the isochronous stream mode on its hardware level, and the cost of a chip is 
less than $20. Consumer DV adopts IEEE1394 as its digital interface standard, 
although the isochronous stream mode does not ensure reliable communication. When 
sending DV stream on IEEE1394, the 80 bytes DIF blocks are aggregated to 
appropriate size, e.g. an IEEE1 394 packet of consumer SD DV stream consists of 6 DIF 
blocks. 8 bytes common isochronous information (CIP) header is prepended to 
aggregated DV packet). Ogawa teaches the transmitting device is coupled to a first 
isochronous compliant network and the receiving device is coupled to a second 
isochronous compliant network (see figure 2). 
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Ogawa does not explicitly generating a cycle record for each isochronous cycle 
of a first isochronous compliant network, wherein each cycle record includes a relative 
timing marker that indicates a timing of the real-time transport protocol data packet 
relative to a cycle master of the first isochronous compliant network. 

Ben-Dor in the same or similar field of endeavor teaches generating a cycle 
record for each isochronous cycle of a first isochronous compliant network, wherein 
each cycle record includes a relative timing marker that indicates a timing of the real- 
time transport protocol data packet relative to a cycle master of the first isochronous 
compliant network (paragraph 0081, 0110, 0012, 0226 cycle_offset 8: This field 
represents an offset to be added to the transmit time on the IEEE-1394 bus and 
inserted in the SYT and/or SPH field within a CIP (Common Isochronous Packet) 
based isochronous packet, bused on the CIP field. Cip 2: This field specifies if the 
current transmit time plus cycle offset should be inserted into the SYT field and/or 
SPH fields on a CIP based packet. The cycle offset is added to the cycle count field 
within IEEE-1934 cycle time. 00b = Do not modify SYT or SPH fields. 01b = Insert 
transmit cycle time plus off- set into the SYT field 10b = Insert transmit cycle time plus 
off- set into the SPH field 11b = Insert transmit cycle time plus off- set into both the 
SYT and SPH fields. The cycle offset field is IEEE-1394 specific and represents the 
cycle offset (from the local bus cycle count) of the actual transmit time from the 
SYT/SPH fields in the Common Isochronous Packet (CIP) used by IEEE-1394 A/V 
devices. This field allows the network host to manage "presentation" times of data over 
IEEE-1394, even though the network host is not aware of the local IEEE-1394 cycle 
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count. The absolute_cycle_time field represents the actual transmit time of the 
isochronous data on the IEEE-1394 local bus. This field allows the network host to 
synchronize its internal cycle count (in software) with the IEEE-1394 cycle count. The 
RPS may choose to throttle the data based on retrieval bandwidth using protocols such 
as RSVP or RTP or QOS Network services). 

Thus, it would have been obvious to one of ordinary skill in the art at the time of 
the invention to use the steps of generating a cycle record for each isochronous cycle of 
a first isochronous compliant network, wherein each cycle record includes a relative 
timing marker that indicates a timing of the real-time transport protocol data packet 
relative to a cycle master of the first isochronous compliant network as taught by Ben- 
Dor the packet processing apparatus, and packet processing method of Ogawa in order 
tot provide necessary timing reference and guidelines for transmitting data to the 
destination device (as suggested by Ben-Dor, paragraph 0226). Known work in one field 
of endeavor may prompt variations of it for use in either the same field or a different one 
based on design incentives or other market forces/market place incentives if the 
variations are predictable to one of ordinary skill in the art. 

Regarding claim 3, Ogawa teaches eaches the first isochronous compliant 
network and the second isochronous compliant network each comprise an IEEE 1394 
compliant bus architecture (see figure 2 IEEE1394 bus). 

Regarding claim 4, Ogawa teaches the first isochronous compliant network and 
the second isochronous compliant network are coupled via the non-isochronous 
compliant network (see figure 2). 
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Regarding claim 5, Ogawa teaches teaches the non-isochronous compliant 
network comprises an Internet Protocol network (see figure 2). 

Regarding claim 6, Ogawa teaches teaches the Internet Protocol network 
comprises an Ethernet/Internet Protocol network (abstract). 

Regarding claim 8, Ogawa teaches the real-time transport protocol defines a 
real-time transport protocol header and a real-time transport protocol data payload for 
each real-time transport protocol data packet (see figure 1). 

Regarding claim 9, Ogawa teaches the real-time transport protocol data payload 
comprises one or more isochronous cycle records (See Section 4.1). 

Regarding claim 10, Ogawa teaches each of the one or more isochronous cycle 
records comprises zero or more isochronous data packets (See Section 4.1). 

Regarding claim 1 1 , Ogawa teaches each isochronous data packet comprises an 
IEEE 1394 isochronous data packet (See Section 4.1). 

Regarding claim 14, Ogawa teaches each real-time transport protocol data 
packet includes at least a portion of an isochronous cycle record (See Section 4.1). 

Regarding claim 15, Ogawa discloses a an apparatus for communicating data 
strasm, that apparatus comprising: a. means for packetizing one or more data streams 
into isochronous data packets; b. means for encapsulating one or more isochronous 
data packets according to a real- time transport protocol to form a real-time transport 
protocol data packet; and c. means for sending the real-time transport protocol data 
packets from a transmitting device to a receiving device over a non-isochronous 
compliant network (sections 4-4.1, we implemented IP based DV video transmission 
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system called DV Transport System(DVTS) using DV/RTP[5][6]. The overview of the 
DVTS is shown in Fig. 2. The system consists of a Pentium based PC with FreeBSD as 
an operating system, IEEE1394 device driver and interface^], and DV/RTP stream 
sender and receiver application. Both DV/RTP sender and receiver PC have an 
IEEE1394 interface on the PCI bus. The camcorder connected DV/RTP sender side 
(Shown in the left side of Fig. 2) creates IEEE1394 encapsulated DV packet stream. 
The sender application receives the DV stream via PCI IEEE1394 interface card, 
encapsulates the DV packet of IEEE1394 into RTP, and transmits it to the IP network. 
The receiver application obtains the IEEE1394 DV packets by reconstructing DV data 
received using RTP. IEEE1394 header is attached to the reconstructed DV/IEEE1394 
packet and transferred to the DV recorder deck via PCI IEEE1394 interface card 
(Shown in the right side of Fig. 2). The DV recorder deck displays the DV data on the 
connected display. The DV system we implemented has the advantage that the system 
can be configured only with highly available standard PCI based PC compatibles, 
consumer DV camcorder and DV VCR equipment having IEEE1394 interface. In order 
to use consumer DV devices equipped with IEEE1394 interface, we designed and 
implemented an IEEE1394 device driver on FreeBSD 3.3[7]. IEEE1394 high speed 
serial bus system is designed for a packet based shared media computer bus system. 
The network bandwidth is logically specified from 100Mbps to 3.2Gbps. The goal of 
IEEE1394 is to integrate and observe various interface and cable specification into only 
single bus (cable) system, i.e. storage device interface instead of SCSI and IDE, 
peripheral of parallel and serial, network of ethernet, processor interconnect of VME and 
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also RCA cable of audio and visual equipment. Heterogeneous speed devices can be 
connected within a single IEEE1394 physical network, which enables devices are made 
at the appropriate cost. Three types of transmission mode is provided by IEEE1394; 
1)isochronous stream mode for QoS which provides especially strict packet jitter and 
guaranteed bandwidth without reliable communication, 2) asynchronous stream for best 
effort without reliability, and 3)asynchronous request for the reliable communication. 
Data timing in IEEE1394 is shown in Fig 3. Every packet transmission action is brought 
with 8 kHz time slice whose value corresponds to the fairness unit in the IEEE1394 
system. The 8kHz time slice unit is also divided into 6144 time slot for bandwidth 
management. Isochronous stream transmission would be done by taking the number of 
time slot the sender requires first, sending a packet whose size is smaller than the time 
slot at every 8kHz fairness unit. Therefore, the packet jitter of the isochronous stream 
mode is suppressed in the order of 8kHz (125 micro second), and the condition might 
be enough for any jitter sensitive high quality packet video system. It is not easy for the 
legacy packet based shared network system to satisfy such conditions. However, every 
IEEE1394 LSI chip already supports the isochronous stream mode on its hardware 
level, and the cost of a chip is less than $20. Consumer DV adopts IEEE1394 as its 
digital interface standard, although the isochronous stream mode does not ensure 
reliable communication. When sending DV stream on IEEE1394, the 80 bytes DIF 
blocks are aggregated to appropriate size, e.g. an IEEE1394 packet of consumer SD 
DV stream consists of 6 DIF blocks. 8 bytes common isochronous information (CIP) 
header is prepended to aggregated DV packet). Ogawa teaches the transmitting device 
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is coupled to a first isochronous compliant network and the receiving device is coupled 
to a second isochronous compliant network (see figure 2). 

Ogawa does not explicitly generating a cycle record for each isochronous cycle 
of a first isochronous compliant network, wherein each cycle record includes a relative 
timing marker that indicates a timing of the real-time transport protocol data packet 
relative to a cycle master of the first isochronous compliant network. 

Ben-Dor in the same or similar field of endeavor teaches generating a cycle 
record for each isochronous cycle of a first isochronous compliant network, wherein 
each cycle record includes a relative timing marker that indicates a timing of the real- 
time transport protocol data packet relative to a cycle master of the first isochronous 
compliant network (paragraph 0081, 0110, 0012, 0226 cycle_offset 8: This field 
represents an offset to be added to the transmit time on the IEEE-1394 bus and 
inserted in the SYT and/or SPH field within a CIP (Common Isochronous Packet) 
based isochronous packet, bused on the CIP field. Cip 2: This field specifies if the 
current transmit time plus cycle offset should be inserted into the SYT field and/or 
SPH fields on a CIP based packet. The cycle offset is added to the cycle count field 
within IEEE-1934 cycle time. 00b = Do not modify SYT or SPH fields. 01b = Insert 
transmit cycle time plus off- set into the SYT field 10b = Insert transmit cycle time plus 
off- set into the SPH field 11b = Insert transmit cycle time plus off- set into both the 
SYT and SPH fields. The cycle offset field is IEEE-1394 specific and represents the 
cycle offset (from the local bus cycle count) of the actual transmit time from the 
SYT/SPH fields in the Common Isochronous Packet (CIP) used by IEEE-1394 A/V 
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devices. This field allows the network host to manage "presentation" times of data over 
IEEE-1394, even though the network host is not aware of the local IEEE-1394 cycle 
count. The absolute_cycle_time field represents the actual transmit time of the 
isochronous data on the IEEE-1394 local bus. This field allows the network host to 
synchronize its internal cycle count (in software) with the IEEE-1394 cycle count. The 
RPS may choose to throttle the data based on retrieval bandwidth using protocols such 
as RSVP or RTP or QOS Network services). 

Thus, it would have been obvious to one of ordinary skill in the art at the time of 
the invention to use the steps of generating a cycle record for each isochronous cycle of 
a first isochronous compliant network, wherein each cycle record includes a relative 
timing marker that indicates a timing of the real-time transport protocol data packet 
relative to a cycle master of the first isochronous compliant network as taught by Ben- 
Dor the packet processing apparatus, and packet processing method of Ogawa in order 
tot provide necessary timing reference and guidelines for transmitting data to the 
destination device (as suggested by Ben-Dor, paragraph 0226). Known work in one field 
of endeavor may prompt variations of it for use in either the same field or a different one 
based on design incentives or other market forces/market place incentives if the 
variations are predictable to one of ordinary skill in the art. 

Regarding claims 17-20, 22-25, 27 and 28, Ogawa teaches discloses all the 
limitations as discussed in the rejection of claims 1-11 and 13-14 and are therefore 
apparatus claims 17-20, 22-25, 27 and 28 are rejected using the same rationales. 
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Regarding claim 62, Ogawa teaches a method of communicating data streams, 
the method comprising: a. packetizing one or more data streams into IEEE 1394 
compliant isochronous data packets; b. encapsulating one or more IEEE 1394 
compliant isochronous data packets according to a real-time transport protocol to form a 
real-time transport protocol data packet; and c. sending the real-time transport protocol 
data packets from a transmitting device to a receiving device over a non-isochronous 
compliant network (sections 4-4.1, we implemented IP based DV video transmission 
system called DV Transport System(DVTS) using DV/RTP[5][6]. The overview of the 
DVTS is shown in Fig. 2. The system consists of a Pentium based PC with FreeBSD as 
an operating system, IEEE1394 device driver and interface^], and DV/RTP stream 
sender and receiver application. Both DV/RTP sender and receiver PC have an 
IEEE1394 interface on the PCI bus. The camcorder connected DV/RTP sender side 
(Shown in the left side of Fig. 2) creates IEEE1394 encapsulated DV packet stream. 
The sender application receives the DV stream via PCI IEEE1394 interface card, 
encapsulates the DV packet of IEEE1394 into RTP, and transmits it to the IP network. 
The receiver application obtains the IEEE1394 DV packets by reconstructing DV data 
received using RTP. IEEE1394 header is attached to the reconstructed DV/IEEE1394 
packet and transferred to the DV recorder deck via PCI IEEE1394 interface card 
(Shown in the right side of Fig. 2). The DV recorder deck displays the DV data on the 
connected display. The DV system we implemented has the advantage that the system 
can be configured only with highly available standard PCI based PC compatibles, 
consumer DV camcorder and DV VCR equipment having IEEE1394 interface. In order 
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to use consumer DV devices equipped with IEEE1394 interface, we designed and 
implemented an IEEE1394 device driver on FreeBSD 3.3[7]. IEEE1394 high speed 
serial bus system is designed for a packet based shared media computer bus system. 
The network bandwidth is logically specified from 100Mbps to 3.2Gbps. The goal of 
IEEE1394 is to integrate and observe various interface and cable specification into only 
single bus (cable) system, i.e. storage device interface instead of SCSI and IDE, 
peripheral of parallel and serial, network of ethernet, processor interconnect of VME and 
also RCA cable of audio and visual equipment. Heterogeneous speed devices can be 
connected within a single IEEE1394 physical network, which enables devices are made 
at the appropriate cost. Three types of transmission mode is provided by IEEE1394; 
1)isochronous stream mode for QoS which provides especially strict packet jitter and 
guaranteed bandwidth without reliable communication, 2) asynchronous stream for best 
effort without reliability, and 3)asynchronous request for the reliable communication. 
Data timing in IEEE1394 is shown in Fig 3. Every packet transmission action is brought 
with 8 kHz time slice whose value corresponds to the fairness unit in the IEEE1394 
system. The 8kHz time slice unit is also divided into 6144 time slot for bandwidth 
management. Isochronous stream transmission would be done by taking the number of 
time slot the sender requires first, sending a packet whose size is smaller than the time 
slot at every 8kHz fairness unit. Therefore, the packet jitter of the isochronous stream 
mode is suppressed in the order of 8kHz (125 micro second), and the condition might 
be enough for any jitter sensitive high quality packet video system. It is not easy for the 
legacy packet based shared network system to satisfy such conditions. However, every 
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IEEE1394 LSI chip already supports the isochronous stream mode on its hardware 
level, and the cost of a chip is less than $20. Consumer DV adopts IEEE1394 as its 
digital interface standard, although the isochronous stream mode does not ensure 
reliable communication. When sending DV stream on IEEE1394, the 80 bytes DIF 
blocks are aggregated to appropriate size, e.g. an IEEE1394 packet of consumer SD 
DV stream consists of 6 DIF blocks. 8 bytes common isochronous information (CIP) 
header is prepended to aggregated DV packet). Ogawa teaches the transmitting device 
is coupled to a first isochronous compliant network and the receiving device is coupled 
to a second isochronous compliant network (see figure 2). 

Ogawa does not explicitly generating a cycle record for each isochronous cycle 
of a first IEEE-1394 compliant network, wherein each cycle record includes a relative 
timing marker that indicates a timing of the real-time transport protocol data packet 
relative to a cycle master of the first IEEE-1 394 compliant network. 

Ben-Dor in the same or similar field of endeavor teaches generating a cycle 
record for each isochronous cycle of a first IEEE-1394 compliant network, wherein each 
cycle record includes a relative timing marker that indicates a timing of the real-time 
transport protocol data packet relative to a cycle master of the first IEEE-1394 compliant 
network (paragraph 0081, 0110, 0012, 0226 cycle_offset 8: This field represents an 
offset to be added to the transmit time on the IEEE-1394 bus and inserted in the SYT 
and/or SPH field within a CIP (Common Isochronous Packet) based isochronous 
packet, bused on the CIP field. Cip 2: This field specifies if the current transmit time 
plus cycle offset should be inserted into the SYT field and/or SPH fields on a CIP 
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based packet. The cycle offset is added to the cycle count field within IEEE-1934 
cycle time. 00b = Do not modify SYT or SPH fields. 01b = Insert transmit cycle time 
plus off- set into the SYT field 10b = Insert transmit cycle time plus off- set into the 
SPH field 11b = Insert transmit cycle time plus off- set into both the SYT and SPH 
fields. The cycle offset field is IEEE-1394 specific and represents the cycle offset (from 
the local bus cycle count) of the actual transmit time from the SYT/SPH fields in the 
Common Isochronous Packet (CIP) used by IEEE-1394 A/V devices. This field allows 
the network host to manage "presentation" times of data over IEEE-1394, even though 
the network host is not aware of the local IEEE-1394 cycle count. The 
absolute_cycle_time field represents the actual transmit time of the isochronous data on 
the IEEE-1394 local bus. This field allows the network host to synchronize its internal 
cycle count (in software) with the IEEE-1394 cycle count. The RPS may choose to 
throttle the data based on retrieval bandwidth using protocols such as RSVP or RTP or 
QOS Network services). 

Thus, it would have been obvious to one of ordinary skill in the art at the time of 
the invention to use the steps of generating a cycle record for each isochronous cycle of 
a first IEEE-1394 compliant network, wherein each cycle record includes a relative 
timing marker that indicates a timing of the real-time transport protocol data packet 
relative to a cycle master of the first IEEE-1394 compliant network as taught by Ben-Dor 
the packet processing apparatus, and packet processing method of Ogawa in order tot 
provide necessary timing reference and guidelines for transmitting data to the 
destination device (as suggested by Ben-Dor, paragraph 0226). Known work in one field 
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of endeavor may prompt variations of it for use in either the same field or a different one 
based on design incentives or other market forces/market place incentives if the 
variations are predictable to one of ordinary skill in the art. 

3. Claim 12 is rejected under 35 U.S.C. 103(a) as being unpatentable over Ogawa 
et al. (Design and implementation of DV based video over RTP. Proc. Packet 
Video2000, 2000), hereinafter Ogawa and Ben-Doras applied to claims 1,15, 29, 43 
and 58 and further in view of Saito et al., hereinafter Saito, (US6523696). 

Regarding claim 12, Ogawa discloses all the subject matter of the claimed 
invention of claims 1 with the exception of each IEEE 1394 isochronous data packet 
includes an IEEE 1394 data payload formatted according to an IEC 61883-1 compliant 
Common Isochronous Protocol (CIP). 

Saito et al. from the same or similar fields of endeavor teaches the use of 
encapsulation of the IEC 61 883 (see Saito et al. column 38 line 2). 

Thus, it would have been obvious to one of ordinary skill in the art at the time of 
the invention to use the encapsulation of the IEC 61883 as taught by Saito et al in the 
packet processing apparatus, and packet processing method of Ogawa in order tot 
provide necessary rules and guidelines for transmitting data (see Saito column 38 line 
5-10 and column 39 line 3-12). 

4. Claims 13, 29-31 , 33-35, 38-50, 53-61 , 64, 65, 68, 69, are rejected under 35 
U.S.C. 103(a) as being unpatentable over Ogawa et al. (Design and implementation of 
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DV based video over RTP. Proc. Packet Video2000, 2000), hereinafter Ogawa and in 
view of Ben-Dor et al., hereinafter Saito, (US PAT PUB 2002/0141418, hereinafter Ben- 
Dor) and Azriel et al. (US PAT 7286652, hereinafter Azriel). 

Regarding claim 13, Ogawa teaches a Packet processing apparatus, and packet 
processing method comprising: a. a packetizing one or more data streams into 
isochronous data packets; b. encapsulating one or more isochronous data packets 
according to a real- time transport protocol to form a real-time transport protocol data 
packet; and c. sending the real-time transport protocol data packets from a transmitting 
device to a receiving device over a non-isochronous compliant network (sections 4-4.1, 
we implemented IP based DV video transmission system called DV Transport 
System(DVTS) using DV/RTP[5][6]. The overview of the DVTS is shown in Fig. 2. The 
system consists of a Pentium based PC with FreeBSD as an operating system, 
IEEE1394 device driver and interface^], and DV/RTP stream sender and receiver 
application. Both DV/RTP sender and receiver PC have an IEEE1394 interface on the 
PCI bus. The camcorder connected DV/RTP sender side (Shown in the left side of Fig. 
2) creates IEEE1394 encapsulated DV packet stream. The sender application receives 
the DV stream via PCI IEEE1394 interface card, encapsulates the DV packet of 
IEEE1394 into RTP, and transmits it to the IP network. The receiver application obtains 
the IEEE1394 DV packets by reconstructing DV data received using RTP. IEEE1394 
header is attached to the reconstructed DV/IEEE1394 packet and transferred to the DV 
recorder deck via PCI IEEE1394 interface card (Shown in the right side of Fig. 2). The 
DV recorder deck displays the DV data on the connected display. The DV system we 
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implemented has the advantage that the system can be configured only with highly 
available standard PCI based PC compatibles, consumer DV camcorder and DV VCR 
equipment having IEEE1394 interface. In order to use consumer DV devices equipped 
with IEEE1394 interface, we designed and implemented an IEEE1394 device driver on 
FreeBSD 3.3[7]. IEEE1394 high speed serial bus system is designed for a packet based 
shared media computer bus system. The network bandwidth is logically specified from 
100Mbps to 3.2Gbps. The goal of IEEE1394 is to integrate and observe various 
interface and cable specification into only single bus (cable) system, i.e. storage device 
interface instead of SCSI and IDE, peripheral of parallel and serial, network of ethernet, 
processor interconnect of VME and also RCA cable of audio and visual equipment. 
Heterogeneous speed devices can be connected within a single IEEE1394 physical 
network, which enables devices are made at the appropriate cost. Three types of 
transmission mode is provided by IEEE1394; 1)isochronous stream mode for QoS 
which provides especially strict packet jitter and guaranteed bandwidth without reliable 
communication, 2) asynchronous stream for best effort without reliability, and 
3)asynchronous request for the reliable communication. Data timing in IEEE1394 is 
shown in Fig 3. Every packet transmission action is brought with 8 kHz time slice whose 
value corresponds to the fairness unit in the IEEE1394 system. The 8kHz time slice unit 
is also divided into 6144 time slot for bandwidth management. Isochronous stream 
transmission would be done by taking the number of time slot the sender requires first, 
sending a packet whose size is smaller than the time slot at every 8kHz fairness unit. 
Therefore, the packet jitter of the isochronous stream mode is suppressed in the order 
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of 8kHz (125 micro second), and the condition might be enough for any jitter sensitive 
high quality packet video system. It is not easy for the legacy packet based shared 
network system to satisfy such conditions. However, every IEEE1394 LSI chip already 
supports the isochronous stream mode on its hardware level, and the cost of a chip is 
less than $20. Consumer DV adopts IEEE1394 as its digital interface standard, 
although the isochronous stream mode does not ensure reliable communication. When 
sending DV stream on IEEE1394, the 80 bytes DIF blocks are aggregated to 
appropriate size, e.g. an IEEE1 394 packet of consumer SD DV stream consists of 6 DIF 
blocks. 8 bytes common isochronous information (CIP) header is prepended to 
aggregated DV packet). Ogawa teaches the transmitting device is coupled to a first 
isochronous compliant network and the receiving device is coupled to a second 
isochronous compliant network (see figure 2). Ogawa teaches the real-time transport 
protocol defines a real-time transport protocol header and a real-time transport protocol 
data payload for each real-time transport protocol data packet (see figure 1) 

Ogawa does not explicitly teach a value of the isochronous cycle start transaction 
corresponding to the receipt of a first isochronous cycle start transaction corresponding 
to the receipt of a first isochronous data packet included in a particular real-time 
transport protocol data packet. 

Ben-Dor in the same or similar field of endeavor teaches a value of the 
isochronous cycle start transaction corresponding to the receipt of a first isochronous 
cycle start transaction corresponding to the receipt of a first isochronous data packet 
included in a particular real-time transport protocol data packet (paragraph 0081, 0110, 
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0012, 0226 cycle_offset 8: This field represents an offset to be added to the transmit 
time on the IEEE-1394 bus and inserted in the SYT and/or SPH field within a CIP 
(Common Isochronous Packet) based isochronous packet, bused on the CIP field. 
Cip 2: This field specifies if the current transmit time plus cycle offset should be 
inserted into the SYT field and/or SPH fields on a CIP based packet. The cycle offset 
is added to the cycle count field within IEEE-1934 cycle time. 00b = Do not modify 
SYT or SPH fields. 01b = Insert transmit cycle time plus off- set into the SYT field 10b 
= Insert transmit cycle time plus off- set into the SPH field 1 1b = Insert transmit cycle 
time plus off- set into both the SYT and SPH fields. The cycle offset field is IEEE-1394 
specific and represents the cycle offset (from the local bus cycle count) of the actual 
transmit time from the SYT/SPH fields in the Common Isochronous Packet (CIP) used 
by IEEE-1394 A/V devices. This field allows the network host to manage "presentation" 
times of data over IEEE-1394, even though the network host is not aware of the local 
IEEE-1394 cycle count. The absolute_cycle_time field represents the actual transmit 
time of the isochronous data on the IEEE-1394 local bus. This field allows the network 
host to synchronize its internal cycle count (in software) with the IEEE-1394 cycle count. 
The RPS may choose to throttle the data based on retrieval bandwidth using protocols 
such as RSVP or RTP or QOS Network services). 

Thus, it would have been obvious to one of ordinary skill in the art at the time of 
the invention to use the steps of a value of the isochronous cycle start transaction 
corresponding to the receipt of a first isochronous cycle start transaction corresponding 
to the receipt of a first isochronous data packet included in a particular real-time 
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transport protocol data packet as taught by Ben-Dor the packet processing apparatus, 
and packet processing method of Ogawa in order tot provide necessary timing 
reference and guidelines for transmitting data to the destination device (as suggested 
by Ben-Dor, paragraph 0226). Known work in one field of endeavor may prompt 
variations of it for use in either the same field or a different one based on design 
incentives or other market forces/market place incentives if the variations are 
predictable to one of ordinary skill in the art. 

Ogawa and Ben-Dor do not explicitly teach sending timing information via RTP 
header. 

Azriel in the same or similar field of endeavor teaches sending timing information 
via RTP header (figure 10, element 262, column 8 lines 17-20, column 15 lines 30-40). 

Thus, it would have been obvious to one of ordinary skill in the art at the time of 
the invention to incorporate in Ogawa and Ben-Dor's system/method the steps of 
sending timing information via RTP header as suggested by Azriel. The motivation is 
that such method enables a device to send accurate timing related information to a 
destination device using RTP header; thus enabling seamless time synchronization over 
RTP protocol. Known work in one field of endeavor may prompt variations of it for use in 
either the same field or a different one based on design incentives or other market 
forces/market place incentives if the variations are predictable to one of ordinary skill in 
the art. 

Regarding claim 29, Ogawa teaches apparatus to communicate data streams, 
the apparatus comprising: • a transmitting circuit (figure 2, DV/RTP sender and receiver 



Application/Control Number: 10/814,848 Page 22 

Art Unit: 2419 

PC ) configured to encapsulate one or more first isochronous data packets according to 
a real-time transport protocol, thereby forming a first real-time transport protocol data 
packet, and to transmit the first real-time transport protocol data packets (Section 4, 
IEEE1394 device driver and interface^], and DV/RTP stream sender and receiver 
application. Both DV/RTP sender and receiver PC have an IEEE1394 interface on the 
PCI bus. The camcorder connected DV/RTP sender side) creates IEEE1394 
encapsulated DV packet stream. The sender application receives the DV stream via 
PCI IEEE1394 interface card, encapsulates the DV packet of IEEE1394 into RTP, and 
transmits it to the IP network); a receiving circuit (figure 2, DV/RTP sender and receiver 
PC) configured to receive a second real-time transport protocol data packet, and to de- 
encapsulate the received second real-time transport protocol data packets into one or 
more second isochronous data packets (Section 4, The receiver application obtains the 
IEEE1394 DV packets by reconstructing DV data received using RTP. IEEE1394 
header is attached to the reconstructed DV/IEEE1394 packet and transferred to the DV 
recorder deck via PCI IEEE1394 interface card). Ogawa teaches the real-time transport 
protocol defines a real-time transport protocol header and a real-time transport protocol 
data payload for each real-time transport protocol data packet (see figure 1). 

Ogawa does not explicitly teach a value of the isochronous cycle start transaction 
corresponding to the receipt of a first isochronous cycle start transaction corresponding 
to the receipt of a first isochronous data packet included in a particular real-time 
transport protocol data packet. 
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Ben-Dor in the same or similar field of endeavor teaches a value of the 
isochronous cycle start transaction corresponding to the receipt of a first isochronous 
cycle start transaction corresponding to the receipt of a first isochronous data packet 
included in a particular real-time transport protocol data packet (paragraph 0081, 0110, 
0012, 0226 cycle_offset 8: This field represents an offset to be added to the transmit 
time on the IEEE-1394 bus and inserted in the SYT and/or SPH field within a CIP 
(Common Isochronous Packet) based isochronous packet, bused on the CIP field. 
Cip 2: This field specifies if the current transmit time plus cycle offset should be 
inserted into the SYT field and/or SPH fields on a CIP based packet. The cycle offset 
is added to the cycle count field within IEEE-1934 cycle time. 00b = Do not modify 
SYT or SPH fields. 01b = Insert transmit cycle time plus off- set into the SYT field 10b 
= Insert transmit cycle time plus off- set into the SPH field 1 1b = Insert transmit cycle 
time plus off- set into both the SYT and SPH fields. The cycle offset field is IEEE-1394 
specific and represents the cycle offset (from the local bus cycle count) of the actual 
transmit time from the SYT/SPH fields in the Common Isochronous Packet (CIP) used 
by IEEE-1394 A/V devices. This field allows the network host to manage "presentation" 
times of data over IEEE-1394, even though the network host is not aware of the local 
IEEE-1394 cycle count. The absolute_cycle_time field represents the actual transmit 
time of the isochronous data on the IEEE-1394 local bus. This field allows the network 
host to synchronize its internal cycle count (in software) with the IEEE-1394 cycle count. 
The RPS may choose to throttle the data based on retrieval bandwidth using protocols 
such as RSVP or RTP or QOS Network services). 
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Thus, it would have been obvious to one of ordinary skill in the art at the time of 
the invention to use the steps of a value of the isochronous cycle start transaction 
corresponding to the receipt of a first isochronous cycle start transaction corresponding 
to the receipt of a first isochronous data packet included in a particular real-time 
transport protocol data packet as taught by Ben-Dor the packet processing apparatus, 
and packet processing method of Ogawa in order tot provide necessary timing 
reference and guidelines for transmitting data to the destination device (as suggested 
by Ben-Dor, paragraph 0226). Known work in one field of endeavor may prompt 
variations of it for use in either the same field or a different one based on design 
incentives or other market forces/market place incentives if the variations are 
predictable to one of ordinary skill in the art. 

Ogawa and Ben-Dor do not explicitly teach sending timing information via RTP 
header. 

Azriel in the same or similar field of endeavor teaches sending timing information 
via RTP header (figure 10, element 262, column 8 lines 17-20, column 15 lines 30-40). 

Thus, it would have been obvious to one of ordinary skill in the art at the time of 
the invention to incorporate in Ogawa and Ben-Dor's system/method the steps of 
sending timing information via RTP header as suggested by Azriel. The motivation is 
that such method enables a device to send accurate timing related information to a 
destination device using RTP header; thus enabling seamless time synchronization over 
RTP protocol. Known work in one field of endeavor may prompt variations of it for use in 
either the same field or a different one based on design incentives or other market 
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forces/market place incentives if the variations are predictable to one of ordinary skill in 
the art. 

In regards to claim 30, Ogawa teaches the transmitting device is coupled to a 
first isochronous compliant network and the receiving device is coupled to a second 
isochronous compliant network (see figure 2). 

Regarding claim 31 Ogawa teaches the first isochronous compliant network and 
the second isochronous compliant network each comprise an IEEE 1394 compliant bus 
architecture (see figure 2 IEEE1394 bus). 

Regarding claim 33, Ogawa teaches the real-time transport protocol data 
payload comprises one or more isochronous (I394) cycle records (See Section 4.1). 

Regarding claim 34 Ogawa teaches each of the one or more isochronous cycle 
records comprises zero or more isochronous data packets (See Section 4.1). 

Regarding claim 35, Ogawa teaches each isochronous data packet comprises an 
IEEE 1394 isochronous data packet (See Section 4.1). 

Regarding claim 38, Ogawa teaches the transmitting circuit is further 
configured to packetize one or more data streams into the one or more isochronous 
data packets (See section 4). 

Regarding claim 39, Ogawa teaches the transmitting circuit is further 
configured to receive the one or more isochronous data packets from another device 
(See sections 4 and 4.1). 
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Regarding claim 40 Ogawa teaches the receiving circuit is further configured to 
parse the one or more isochronous data packets (I394) from each received real-time 
transport protocol data packet (See sections 4 and 4.1). 

Regarding claim 41 Ogawa teaches each real-time transport protocol data packet 
includes at least a portion of an isochronous cycle record (See Section 4.1). 

Regarding claim 42 Ogawa teaches each of the one or more isochronous cycle 
records comprises zero or more isochronous data packets (See Section 4.1). 

Regarding claim 43, Kanehara a network of devices to communicate data 
streams, the network of devices comprising: a. a transmitting device configured to 
encapsulate one or more isochronous data packets according to a real-time transport 
protocol, thereby forming a real-time transport protocol data packet, and to transmit the 
real-time transport protocol data packets; b. a first isochronous compliant network 
coupled to the transmitting device; c. a receiving device configured to receive the real- 
time transport protocol data packets; d. a second isochronous compliant network 
coupled to the receiving device; and e. a network coupled to the first isochronous 
compliant network and the second isochronous compliant network to transmit the real- 
time transport protocol data packets from the transmitting device to the receiving device; 
a non-isochronous compliant network coupled to the receiving device; and Saito the 
same or similar fields of endeavor teaches the use of public network such as internet, 
and the ATM network exists between them (sections 4-4.1, we implemented IP based 
DV video transmission system called DV Transport System(DVTS) using DV/RTP[5][6]. 
The overview of the DVTS is shown in Fig. 2. The system consists of a Pentium based 
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PC with FreeBSD as an operating system, IEEE1394 device driver and interface^], and 
DV/RTP stream sender and receiver application. Both DV/RTP sender and receiver PC 
have an IEEE1394 interface on the PCI bus. The camcorder connected DV/RTP sender 
side (Shown in the left side of Fig. 2) creates IEEE1394 encapsulated DV packet 
stream. The sender application receives the DV stream via PCI IEEE1394 interface 
card, encapsulates the DV packet of IEEE1394 into RTP, and transmits it to the IP 
network. The receiver application obtains the IEEE1394 DV packets by reconstructing 
DV data received using RTP. IEEE1394 header is attached to the reconstructed 
DV/IEEE1394 packet and transferred to the DV recorder deck via PCI IEEE1394 
interface card (Shown in the right side of Fig. 2). The DV recorder deck displays the DV 
data on the connected display. The DV system we implemented has the advantage that 
the system can be configured only with highly available standard PCI based PC 
compatibles, consumer DV camcorder and DV VCR equipment having IEEE1394 
interface. In order to use consumer DV devices equipped with IEEE1394 interface, we 
designed and implemented an IEEE1394 device driver on FreeBSD 3.3[7]. IEEE1394 
high speed serial bus system is designed for a packet based shared media computer 
bus system. The network bandwidth is logically specified from 100Mbps to 3.2Gbps. 
The goal of IEEE1394 is to integrate and observe various interface and cable 
specification into only single bus (cable) system, i.e. storage device interface instead of 
SCSI and IDE, peripheral of parallel and serial, network of ethernet, processor 
interconnect of VME and also RCA cable of audio and visual equipment. 
Heterogeneous speed devices can be connected within a single IEEE1394 physical 
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network, which enables devices are made at the appropriate cost. Three types of 
transmission mode is provided by IEEE1394; 1)isochronous stream mode for QoS 
which provides especially strict packet jitter and guaranteed bandwidth without reliable 
communication, 2) asynchronous stream for best effort without reliability, and 
3)asynchronous request for the reliable communication. Data timing in IEEE1394 is 
shown in Fig 3. Every packet transmission action is brought with 8 kHz time slice whose 
value corresponds to the fairness unit in the IEEE1394 system. The 8kHz time slice unit 
is also divided into 6144 time slot for bandwidth management. Isochronous stream 
transmission would be done by taking the number of time slot the sender requires first, 
sending a packet whose size is smaller than the time slot at every 8kHz fairness unit. 
Therefore, the packet jitter of the isochronous stream mode is suppressed in the order 
of 8kHz (125 micro second), and the condition might be enough for any jitter sensitive 
high quality packet video system. It is not easy for the legacy packet based shared 
network system to satisfy such conditions. However, every IEEE1394 LSI chip already 
supports the isochronous stream mode on its hardware level, and the cost of a chip is 
less than $20. Consumer DV adopts IEEE1394 as its digital interface standard, 
although the isochronous stream mode does not ensure reliable communication. When 
sending DV stream on IEEE1394, the 80 bytes DIF blocks are aggregated to 
appropriate size, e.g. an IEEE1394 packet of consumer SD DV stream consists of 6 DIF 
blocks. 8 bytes common isochronous information (CIP) header is prepended to 
aggregated DV packet). Ogawa teaches the real-time transport protocol defines a real- 
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time transport protocol header and a real-time transport protocol data payload for each 
real-time transport protocol data packet (see figure 1). 

Ogawa does not explicitly teach a value of the isochronous cycle start transaction 
corresponding to the receipt of a first isochronous cycle start transaction corresponding 
to the receipt of a first isochronous data packet included in a particular real-time 
transport protocol data packet. 

Ben-Dor in the same or similar field of endeavor teaches a value of the 
isochronous cycle start transaction corresponding to the receipt of a first isochronous 
cycle start transaction corresponding to the receipt of a first isochronous data packet 
included in a particular real-time transport protocol data packet (paragraph 0081, 0110, 
0012, 0226 cycle_offset 8: This field represents an offset to be added to the transmit 
time on the IEEE-1394 bus and inserted in the SYT and/or SPH field within a CIP 
(Common Isochronous Packet) based isochronous packet, bused on the CIP field. 
Cip 2: This field specifies if the current transmit time plus cycle offset should be 
inserted into the SYT field and/or SPH fields on a CIP based packet. The cycle offset 
is added to the cycle count field within IEEE-1934 cycle time. 00b = Do not modify 
SYT or SPH fields. 01b = Insert transmit cycle time plus off- set into the SYT field 10b 
= Insert transmit cycle time plus off- set into the SPH field 1 1b = Insert transmit cycle 
time plus off- set into both the SYT and SPH fields. The cycle offset field is IEEE-1394 
specific and represents the cycle offset (from the local bus cycle count) of the actual 
transmit time from the SYT/SPH fields in the Common Isochronous Packet (CIP) used 
by IEEE-1394 A/V devices. This field allows the network host to manage "presentation" 
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times of data over IEEE-1394, even though the network host is not aware of the local 
IEEE-1394 cycle count. The absolute_cycle_time field represents the actual transmit 
time of the isochronous data on the IEEE-1394 local bus. This field allows the network 
host to synchronize its internal cycle count (in software) with the IEEE-1394 cycle count. 
The RPS may choose to throttle the data based on retrieval bandwidth using protocols 
such as RSVP or RTP or QOS Network services). 

Thus, it would have been obvious to one of ordinary skill in the art at the time of 
the invention to use the steps of a value of the isochronous cycle start transaction 
corresponding to the receipt of a first isochronous cycle start transaction corresponding 
to the receipt of a first isochronous data packet included in a particular real-time 
transport protocol data packet as taught by Ben-Dor the packet processing apparatus, 
and packet processing method of Ogawa in order tot provide necessary timing 
reference and guidelines for transmitting data to the destination device (as suggested 
by Ben-Dor, paragraph 0226). Known work in one field of endeavor may prompt 
variations of it for use in either the same field or a different one based on design 
incentives or other market forces/market place incentives if the variations are 
predictable to one of ordinary skill in the art. 

Ogawa and Ben-Dor do not explicitly teach sending timing information via RTP 
header. 

Azriel in the same or similar field of endeavor teaches sending timing information 
via RTP header (figure 10, element 262, column 8 lines 17-20, column 15 lines 30-40). 
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Thus, it would have been obvious to one of ordinary skill in the art at the time of 
the invention to incorporate in Ogawa and Ben-Dor's system/method the steps of 
sending timing information via RTP header as suggested by Azriel. The motivation is 
that such method enables a device to send accurate timing related information to a 
destination device using RTP header; thus enabling seamless time synchronization over 
RTP protocol. Known work in one field of endeavor may prompt variations of it for use in 
either the same field or a different one based on design incentives or other market 
forces/market place incentives if the variations are predictable to one of ordinary skill in 
the art. 

Regarding claim 44 Ogawa teaches the first isochronous compliant network and 
the second isochronous compliant network each comprise an IEEE 1394 compliant bus 
architecture (see figure 2 IEEE1394 bus). 

Regarding claim 48 Ogawa teaches each real-time transport protocol data packet 
includes at least a portion of an isochronous cycle record (See Section 4.1). 

Regarding claim 49 Ogawa teaches each of the one or more isochronous cycle 
records comprises zero or more isochronous data packets (See Section 4.1). 

Regarding claim 45, Ogawa teaches the non-isochronous compliant network 
comprises an Internet Protocol network (see figure 2). 

Regarding claim 46 Ogawa teaches the Internet Protocol network comprises an 
Ethernet/Internet Protocol network (see Abstract). 
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Regarding claim 55 Ogawa teaches the receiving circuit is further configured to 
parse the one or more isochronous data packets (I394) from each received real-time 
transport protocol data packet (See sections 4 and 4.1). 

Regarding claim 56 Ogawa teaches the real-time transport protocol data payload 
comprises one or more isochronous (I394) cycle records (See Section 4.1). 

Regarding claim 57 Ogawa teaches each of the one or more isochronous cycle 
records comprises zero or more isochronous data packets (See Section 4.1). 

Regarding claim 50 Ogawa teaches each isochronous data packet comprises an 
IEEE 1394 isochronous data packet (See Section 4.1). 

Regarding claim 53 Ogawa teaches the transmitting circuit is further 
configured to packetize one or more data streams into the one or more isochronous 
data packets (See section 4). 

Regarding claim 54 Ogawa teaches the transmitting circuit is further 
configured to receive the one or more isochronous data packets from another device 
(See sections 4 and 4.1). 

Regarding claim 58, Ogawa teaches a method of communicating data streams, 
the method comprising: a. packetizing one or more data streams into IEEE 1394 
compliant isochronous data packets; b. encapsulating one or more IEEE 1394 
compliant isochronous data packets according to a real-time transport protocol to form a 
real-time transport protocol data packet; and c. sending the real-time transport protocol 
data packets from a transmitting device to a receiving device over a non-isochronous 
compliant network (sections 4-4.1, we implemented IP based DV video transmission 
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system called DV Transport System(DVTS) using DV/RTP[5][6]. The overview of the 
DVTS is shown in Fig. 2. The system consists of a Pentium based PC with FreeBSD as 
an operating system, IEEE1394 device driver and interface^], and DV/RTP stream 
sender and receiver application. Both DV/RTP sender and receiver PC have an 
IEEE1394 interface on the PCI bus. The camcorder connected DV/RTP sender side 
(Shown in the left side of Fig. 2) creates IEEE1394 encapsulated DV packet stream. 
The sender application receives the DV stream via PCI IEEE1394 interface card, 
encapsulates the DV packet of IEEE1394 into RTP, and transmits it to the IP network. 
The receiver application obtains the IEEE1394 DV packets by reconstructing DV data 
received using RTP. IEEE1394 header is attached to the reconstructed DV/IEEE1394 
packet and transferred to the DV recorder deck via PCI IEEE1394 interface card 
(Shown in the right side of Fig. 2). The DV recorder deck displays the DV data on the 
connected display. The DV system we implemented has the advantage that the system 
can be configured only with highly available standard PCI based PC compatibles, 
consumer DV camcorder and DV VCR equipment having IEEE1394 interface. In order 
to use consumer DV devices equipped with IEEE1394 interface, we designed and 
implemented an IEEE1394 device driver on FreeBSD 3.3[7]. IEEE1394 high speed 
serial bus system is designed for a packet based shared media computer bus system. 
The network bandwidth is logically specified from 100Mbps to 3.2Gbps. The goal of 
IEEE1394 is to integrate and observe various interface and cable specification into only 
single bus (cable) system, i.e. storage device interface instead of SCSI and IDE, 
peripheral of parallel and serial, network of ethernet, processor interconnect of VME and 
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also RCA cable of audio and visual equipment. Heterogeneous speed devices can be 
connected within a single IEEE1394 physical network, which enables devices are made 
at the appropriate cost. Three types of transmission mode is provided by IEEE1394; 
1)isochronous stream mode for QoS which provides especially strict packet jitter and 
guaranteed bandwidth without reliable communication, 2) asynchronous stream for best 
effort without reliability, and 3)asynchronous request for the reliable communication. 
Data timing in IEEE1394 is shown in Fig 3. Every packet transmission action is brought 
with 8 kHz time slice whose value corresponds to the fairness unit in the IEEE1394 
system. The 8kHz time slice unit is also divided into 6144 time slot for bandwidth 
management. Isochronous stream transmission would be done by taking the number of 
time slot the sender requires first, sending a packet whose size is smaller than the time 
slot at every 8kHz fairness unit. Therefore, the packet jitter of the isochronous stream 
mode is suppressed in the order of 8kHz (125 micro second), and the condition might 
be enough for any jitter sensitive high quality packet video system. It is not easy for the 
legacy packet based shared network system to satisfy such conditions. However, every 
IEEE1394 LSI chip already supports the isochronous stream mode on its hardware 
level, and the cost of a chip is less than $20. Consumer DV adopts IEEE1394 as its 
digital interface standard, although the isochronous stream mode does not ensure 
reliable communication. When sending DV stream on IEEE1394, the 80 bytes DIF 
blocks are aggregated to appropriate size, e.g. an IEEE1394 packet of consumer SD 
DV stream consists of 6 DIF blocks. 8 bytes common isochronous information (CIP) 
header is prepended to aggregated DV packet). Ogawa teaches the real-time transport 
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protocol defines a real-time transport protocol header and a real-time transport protocol 
data payload for each real-time transport protocol data packet (see figure 1). 

Ogawa does not explicitly teach a value of the isochronous cycle start transaction 
corresponding to the receipt of a first isochronous cycle start transaction corresponding 
to the receipt of a first isochronous data packet included in a particular real-time 
transport protocol data packet. 

Ben-Dor in the same or similar field of endeavor teaches a value of the 
isochronous cycle start transaction corresponding to the receipt of a first isochronous 
cycle start transaction corresponding to the receipt of a first isochronous data packet 
included in a particular real-time transport protocol data packet (paragraph 0081, 0110, 
0012, 0226 cycle_offset 8: This field represents an offset to be added to the transmit 
time on the IEEE-1394 bus and inserted in the SYT and/or SPH field within a CIP 
(Common Isochronous Packet) based isochronous packet, bused on the CIP field. 
Cip 2: This field specifies if the current transmit time plus cycle offset should be 
inserted into the SYT field and/or SPH fields on a CIP based packet. The cycle offset 
is added to the cycle count field within IEEE-1934 cycle time. 00b = Do not modify 
SYT or SPH fields. 01b = Insert transmit cycle time plus off- set into the SYT field 10b 
= Insert transmit cycle time plus off- set into the SPH field 1 1b = Insert transmit cycle 
time plus off- set into both the SYT and SPH fields. The cycle offset field is IEEE-1394 
specific and represents the cycle offset (from the local bus cycle count) of the actual 
transmit time from the SYT/SPH fields in the Common Isochronous Packet (CIP) used 
by IEEE-1394 A/V devices. This field allows the network host to manage "presentation" 



Application/Control Number: 10/814,848 Page 36 

Art Unit: 2419 

times of data over IEEE-1394, even though the network host is not aware of the local 
IEEE-1394 cycle count. The absolute_cycle_time field represents the actual transmit 
time of the isochronous data on the IEEE-1394 local bus. This field allows the network 
host to synchronize its internal cycle count (in software) with the IEEE-1394 cycle count. 
The RPS may choose to throttle the data based on retrieval bandwidth using protocols 
such as RSVP or RTP or QOS Network services). 

Thus, it would have been obvious to one of ordinary skill in the art at the time of 
the invention to use the steps of a value of the isochronous cycle start transaction 
corresponding to the receipt of a first isochronous cycle start transaction corresponding 
to the receipt of a first isochronous data packet included in a particular real-time 
transport protocol data packet as taught by Ben-Dor the packet processing apparatus, 
and packet processing method of Ogawa in order tot provide necessary timing 
reference and guidelines for transmitting data to the destination device (as suggested 
by Ben-Dor, paragraph 0226). Known work in one field of endeavor may prompt 
variations of it for use in either the same field or a different one based on design 
incentives or other market forces/market place incentives if the variations are 
predictable to one of ordinary skill in the art. 

Ogawa and Ben-Dor do not explicitly teach sending timing information via RTP 
header. 

Azriel in the same or similar field of endeavor teaches sending timing information 
via RTP header (figure 10, element 262, column 8 lines 17-20, column 15 lines 30-40). 
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Thus, it would have been obvious to one of ordinary skill in the art at the time of 
the invention to incorporate in Ogawa and Ben-Dor's system/method the steps of 
sending timing information via RTP header as suggested by Azriel. The motivation is 
that such method enables a device to send accurate timing related information to a 
destination device using RTP header; thus enabling seamless time synchronization over 
RTP protocol. Known work in one field of endeavor may prompt variations of it for use in 
either the same field or a different one based on design incentives or other market 
forces/market place incentives if the variations are predictable to one of ordinary skill in 
the art. 

Regarding claim 59 Ogawa teaches the first isochronous compliant network and 
the second isochronous compliant network each comprise an IEEE 1394 compliant bus 
architecture (see figure 2 IEEE1394 bus). 

Regarding claim 64 and 69 Ogawa teaches the real-time transport protocol data 
payload comprises one or more isochronous (I394) cycle records (See Section 4.1). 

Regarding claim 65 Ogawa teaches each of the one or more isochronous cycle 
records comprises zero or more isochronous data packets (See Section 4.1). 

Regarding claim 68 Ogawa teaches the receiving circuit is further configured to 
parse the one or more isochronous data packets (I394) from each received real-time 
transport protocol data packet (See sections 4 and 4.1). 

Regarding claims 60, Ogawa teaches the non-isochronous compliant network 
comprises an Internet Protocol network (see figure 2). 
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Regarding claims 61 Ogawa teaches the Internet Protocol network comprises an 
Ethernet/Internet Protocol network (see Abstract). 

5. Claims 26, 36, 51 , and 66 are rejected under 35 U.S.C. 1 03(a) as being 
unpatentable over Ogawa et al. (Design and implementation of DV based video over 
RTP. Proc. Packet Video2000, 2000), hereinafter Ogawa, Ben-Dor and Azriel as 
applied to claims 29, 43 and 58 and further in view of Saito et al., hereinafter Saito, 
(US6523696). 

Regarding claim 26, Ogawa discloses all the subject matter of the claimed 
invention of claims 1 and 15 with the exception of each IEEE 1394 isochronous data 
packet includes an IEEE 1394 data payload formatted according to an IEC 61883-1 
compliant Common Isochronous Protocol (CIP). 

Saito et al. from the same or similar fields of endeavor teaches the use of 
encapsulation of the IEC 61 883 (see Saito et al. column 38 line 2). 

Thus, it would have been obvious to one of ordinary skill in the art at the time of 
the invention to use the encapsulation of the IEC 61883 as taught by Saito et al in the 
packet processing apparatus, and packet processing method/system of Ogawa, Ben- 
Dor and Azriel in order tot provide necessary rules and guidelines for transmitting data 
(see Saito column 38 line 5-10 and column 39 line 3-12). 

Regarding claims 36, 51, and 66, Ogawa discloses all the subject matter of the 
claimed invention of claims 29, 43 and 58 with the exception of each IEEE 1394 
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isochronous data packet includes an IEEE 1394 data payload formatted according to an 
IEC 61883-1 compliant Common Isochronous Protocol (CIP). 

Saito et al. from the same or similar fields of endeavor teaches the use of 
encapsulation of the IEC 61 883 (see Saito et al. column 38 line 2). 

Thus, it would have been obvious to one of ordinary skill in the art at the time of 
the invention to use the encapsulation of the IEC 61883 as taught by Saito et al in the 
packet processing apparatus, and packet processing method/system of Ogawa, Ben- 
Dor and Azriel in order tot provide necessary rules and guidelines for transmitting data 
(see Saito column 38 line 5-10 and column 39 line 3-12). 

Response to Arguments 
6. Applicant's arguments see pages 11-13 of the Remarks section, filed 2/16/2009, 
with respect to the rejections of the claims have been fully considered and are moot in 
view of the new ground of rejections presented in this office action. 

Conclusion 

Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to SALMAN AHMED whose telephone number is 
(571)272-8307. The examiner can normally be reached on 9:00 am - 5:30 pm. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Edan Orgad can be reached on (571) 272-7884. The fax phone number for 
the organization where this application or proceeding is assigned is 571-273-8300. 
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Information regarding the status of an application may be obtained from the 
Patent Application Information Retrieval (PAIR) system. Status information for 
published applications may be obtained from either Private PAIR or Public PAIR. 
Status information for unpublished applications is available through Private PAIR only. 
For more information about the PAIR system, see http://pair-direct.uspto.gov. Should 
you have questions on access to the Private PAIR system, contact the Electronic 
Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a 
USPTO Customer Service Representative or access to the automated information 
system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000. 

/Salman Ahmed/ 

Examiner, Art Unit 2419 



